Thanks for the effort with the PR :). However, I have a very big concern I'd like to discuss: consumer coupling.

The current implementation is built under an assumption: the project's main module imports and configures Mini and modules provide extra stores or actions for the main Mini to link. While this approach may make sense in a multi-module project, if we bundle Mini inside a library, it would require that any module consuming it must:

1. Be aware that Mini is being used in the library

2. Know about and explicitly instantiate the library's `Store` classes in the module

3. Pass those stores to `Mini.link()`

This means that if a library uses Mini internally, its consumers are forced to depend on Mini too. That breaks a fundamental principle of library design: implementation details must stay internal. A consumer of a library should just call its public API, not know or care that it uses Mini under the hood.

We have to rethink this approach before we can merge this. The main blocker that currently disallows using it with multiple modules is that we currently create a unique Mini_Generated per project, no matter the modules or libraries that it contains, and that single instance is used by the Mini code to glue everything together. In the multi-module scenario, or lib + consumer that also uses Mini the build doesn't know which Mini_Generated prevails in compilation time and breaks. We should study how to create multiple instances so each module bundles its own Mini and we don't leak it so consumers don't need to implement it to use the module or lib.

One option that comes to my mind is to generate a MiniComponent or something like that that only belongs to the module where Mini is imported, and use that class to link everything inside the module. That way we wouldn't have any issues regarding multi-module conflicts and it would keep the Mini usage as implementation detail of the module or lib, so consumers don't need to implement Mini themselves. We may keep the concept of registries to do this too.

What I have implemented now is a module-local Mini runtime model:

• each module generates its own local MiniRegistry
• generated registries are unique per module, so there are no class collisions
• Mini no longer does global discovery or cross-module composition
• each module links its own reducers explicitly with its own generated registry
• a library can keep Mini fully internal to the module and expose only its public API
• consumers no longer need to know Mini exists, instantiate the module’s stores, or call Mini.link() for that module
  In practice, the generated registry now belongs to the module that owns the Mini wiring, and Mini is no longer treated as a single project-wide glue point. We also validated this in two ways:
• an in-repo module sample for the internal-module case
• an external consumer sample under samples/isolated-consumer for the library/consumer case
  So the new model is much closer to the “MiniComponent per module” direction you suggested, while keeping MiniRegistry as the local bootstrap abstraction.